-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added --permissive-dual-issue flag #27
Conversation
It enables instructions that otherwise aren't allowed in the second issue slot to be allowed. The only restriction is that only one of each type is allowed to be enabled at a time.
OK, good idea. However, I would not allow a load and store both enabled. This is hard to support in hardware. |
Ok, I'll disallow store and load together. |
Like other loads/stores, stack load/store now only allowed in second issue slot when using the '--permissive-dual-issue' flag. Also no longer allows two stack loads/stores enabled in the same bundle.
This is because implemented allowing that in hardware would be difficult.
I have added 2 more cases to the bundling:
Question: Does it make sense to allow a stack load/store with, e.g., a call (even if the call will need to load memory)? This is currently allowed |
Now also cannot bundle two main-memory operations and two stack operations.
Probably not good to mix a load with a call.Cheers,MartinOn 7 Sep 2023, at 12.16, Emad Jacob Maroun ***@***.***> wrote:
I have added 3 more cases to the bundling:
Disallow 2 main-memory targeting instructions. E.g., cannot do a data-cache load and a call the call must fetch instruction and the cache might miss.
Disallow 2 stack operations like in #25 (this is a temporary solution until that issue is decided)
Question: Does it make sense to allow a stack load/store with, e.g., a call (even if the call will need to load memory)? This is currently allowed
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
What do you mean by "not good"? Are there any hardware limitations you can think of? |
As you correctly stated that a call needs to access memory (for the function size) and a load don’t work together.
Martin
… On 10.09.2023, at 12:20, Emad Jacob Maroun ***@***.***> wrote:
What do you mean by "not good"? Are there any hardware limitations you can think of?
The compiler could take advantage of allowing it.
—
Reply to this email directly, view it on GitHub <#27 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE63GHX4TDOAH2GM4QJQV3XZWH5DANCNFSM6AAAAAA4KOEYNE>.
You are receiving this because you commented.
|
But here we are talking about only stack load/stores, which don't touch main memory, so no contention there. |
You are right. |
Ok, I will keep the rules and requirements as is right now. Also, commented out code as specified in #28 . |
'--permissive-dual-issue' flag is meant to test the effect of allowing some instructions of the instructions currently disallowed in the second issue slot.
Currently this enables loads, stores, and branches in the second issue slot with the following requirement:
Only 1 instructions of each kind may be enabled in a bundle, i.e., if there are two loads in a bundle an error will be thrown if they are both enabled. This "check" is done in the simulator at runtime and is thus a guarantee the programmer/compiler provides. The idea is the hardware can treat a violation as undefined behavior (i.e., hardware can do whatever it wants).
I have chosen to allow a store and a load to be enabled in the same bundle. This is assuming the load and store hardware is separate and may be able to execute a load and a store simultaneously , which does seem to be common but I haven't checked whether Patmos can easily implement this.
Also fixed #17